ソフトウェアプロジェクトは、ソフトウェア開発の資金調達と組織化において一般的な方法です。プロジェクトは、一時的な構築専用のチームに作業を編成し、ビジネスケースで予測される具体的なメリットによって資金提供されます。一方、プロダクトモードでは、持続的なビジネス課題に取り組む、アイデア創出・構築・運用を行う恒久的なチームを使用します。プロダクトモードにより、チームは迅速に方向転換し、エンドツーエンドのサイクルタイムを短縮し、短サイクルのイテレーションを使用して実際のメリットを検証しながら、ソフトウェアのアーキテクチャの整合性を維持し、長期的な有効性を確保できます。

既存のソフトウェアシステムを置き換える必要に直面した組織は、しばしば中途半端なテクノロジー置き換えのサイクルに陥ります。私たちの経験から、このサイクルを打破するためのパターンをいくつか学びました。それは、レガシーソフトウェアの置き換えによる望ましい結果を意識的に認識し、この置き換えを部分的に分割し、これらの部分を段階的に提供し、変化が不変の現実であることを認識するよう組織の文化を変えることです。

テクノロジーを効果的に活用するには、テクノロジーに関する考え方と基礎となるビジネスプランを整合させる必要があります。テクノロジー戦略は、ビジネスとテクノロジーを適切に統合することで、この整合性を促進できます。私たちは、戦略的イニシアチブの共通点を認識することに基づいて、この戦略的思考を支援するための概念的フレームワークを開発し、11の一般的な戦略的方向性を特定しました。それぞれの方向性について、それらが提起する主要なビジネス上の課題と、テクノロジーへの影響を探るために必要な調査の概要を示します。このフレームワークは、より効果的なテクノロジー戦略につながるだけでなく、テクノロジーがビジネス思考に情報を提供し、新しい収益源を生み出すことを可能にすると分かりました。

優れた技術設計上の決定は、コンテキストに大きく依存します。共通の目標に向かって定期的に協力するチームは、定期的にコミュニケーションを取り、変更を迅速に交渉できます。これらのチームは、強い力の整合性を示し、その強い力を利用した技術と設計上の決定を下すことができます。より大規模な組織で拡大すると、独立して働き、コラボレーションの頻度が低いチームや部門間には、ますます弱い力が存在します。これらの強い力と弱い力の違いを認識することで、より良い決定を下し、各レベルに適切なガイダンスを提供し、より迅速に動ける権限を与えられたチームを可能にします。

アーキテクチャは、一元化された少数の人の頭脳と口からトップダウンで提供される独り言である必要はありません。この記事では、分散型でエンパワメントされた意思決定手法によって推進され、意思決定記録、アドバイザリーフォーラム、チームソースの原則、テクノロジーレーダーという4つの学習と整合メカニズムによってサポートされる、会話の一連としてアーキテクチャを行う別の方法について説明します。

モジュラーアーキテクチャはソフトウェアデリバリーを改善できますか？はい！—ただし、いくつかの注意点があります。この記事では、成長痛を軽減するためにアーキテクチャをよりモジュラーなものに移行しようとした企業の取り組みを紹介します。彼らは、モジュール性はアーキテクチャを超えて、コミュニケーションのビジネスライン、チームトポロジー、効果的な開発者エクスペリエンスにまで及ぶ多面的なソリューションであることを発見しました。これらの要因に十分に注意することで、企業はモバイルアプリケーションのデリバリーパフォーマンスを大幅に向上させることができました。

XapoはBitcoinサービスプロバイダーとして設立され、オンライン銀行に発展しました。この移行において、ソフトウェア資産を再評価し、将来を導くアーキテクチャ機能を確立する必要がありました。ドメイン駆動設計、チームトポロジー、アーキテクチャアドバイザープロセスからアイデアを取り入れ、アーキテクチャアドバイザリーフォーラムを開発しました。これにより、ソフトウェアデリバリーチームの整合性が向上し、一貫性のあるテクノロジー戦略が確立されました。

商用統合ツールはすでに20年近くの歴史がありますが、いつどのように使用するべきかを説明する包括的なアーキテクチャ原則はほとんどありません。この記事では、「購入」決定メカニズムが、これらのツールの価値提案を誇張し、多くの場合、汎用言語よりも特定の統合ツールを使用することを義務付けることにつながったと主張します。このようなツールは、統合を主にシステムの接続とみなす世界で繁栄しますが、デジタル組織は統合を主にデジタル機能の前にクリーンなインターフェースを置くこと、システムよりも機能を重視することに再定義したと主張します。最後に、最新の統合観点の背後にある主要な原則をいくつかリストし、それらは汎用言語で最も適切に管理され、商用統合ツールの主要な価値提案を戦術的な実装に関する懸念事項の簡素化に向け直すと主張します。

インフラストラクチャプラットフォームチームは、回復力のあるソリューションを使用して共通のプロダクトと非機能要件を解決することで、組織がデリバリーをスケーリングできるようにします。これにより、他のチームは独自のものの構築とユーザーへの価値の提供に集中できます。しかし、スケーラブルなプラットフォームの構築が容易であるとは誰も言っていません...この記事で、PoppyとChrisは、正しいものを正しく構築するのに役立つ7つの主要な原則を探ります。ネタバレ：戦略、ユーザーエクスペリエンス、リサーチをスキップしないでください。

DevOps文化内でコンプライアンス要件を満たすために必要なセキュリティコントロールと監査機能を統合することで、CI/CDパイプラインの自動化を活用できますが、組織がスケールするにつれて独自の課題が生じます。選択した実装によって引き起こされる二次的な影響と意図しない結果を理解することは、効果的で安全でスケーラブルなソリューションを構築するための鍵です。

組織がアジャイルな考え方を取り入れる場合、エンタープライズアーキテクチャは消えるわけではありませんが、エンタープライズアーキテクトの役割は変化します。エンタープライズアーキテクトはもはや選択を行うのではなく、他者が正しい選択を行うのを支援し、その情報を伝えます。エンタープライズアーキテクトは依然としてビジョンを形成する必要がありますが、その後はチーム間の橋渡しを行い、学習コミュニティを構築する必要があります。これにより、チームは新しいアプローチを探求し、互いに学び合うことができ、エンタープライズアーキテクトはその成長のパートナーとなります。

私たちと私たちの同僚は、しばしばクライアントのためにアーキテクチャ評価を実施するよう求められます。これを行う際に、これらのシステムに関与するアーキテクトは、これらのシステムのパフォーマンス、障害に対する回復力、新しい機能を容易にサポートするように設計されている方法について説明します。しかし、めったに話題にならない盲点は、さまざまなシステムがビジネス価値にどのように貢献し、この価値が他のアーキテクチャ属性とどのように相互作用するかです。

多くの巨大企業では、ITエンジンがエグゼクティブペントハウスから多くの階層で分離されており、ビジネスとデジタル戦略がそれを実行する重要な作業からも分離されています。アーキテクトの主要な役割は、ペントハウスと機関室の間でエレベーターに乗り、これらのデジタル活動を支援するために必要な場所に停車することです。ソフトウェア製造の自動化、事前決定の最小化、テクノロジーの進化とともに組織への影響などです。

アーキテクチャのエネルギーのかなりの部分が、ロックインの削減または回避に費やされています。これはかなり崇高な目標です。アーキテクチャは私たちに選択肢を与えることを目的としており、ロックインはその反対です。しかし、ロックインは単純な真偽の問題ではありません。ある側面へのロックインを回避することは、しばしば別の側面へのロックインにつながります。また、オープンソースが自動的にロックインを排除するという一般的な考え方は、完全に正しいとは限りません。ロックインを詳しく見て、ロックイン回避に固執して閉じ込められないようにしましょう！

ほとんどの内部REST APIは、単一の統合ポイント用に特別に構築された一度限りのAPIです。この記事では、非公開APIで利用できる制約と柔軟性、および複数のチームにわたる大規模なRESTful統合を行うことで得られた教訓について説明します。

理想的な状態において、プロダクトモード組織は、緩やかに結合された自律的なチームで構成され、明確に表現されたユーザーニーズと潜在的なユーザーニーズに迅速に対応します。しかし、時折、複数のチームにわたる連携が必要となる機会が生じます。これを効果的に管理しないと、収益の損失、顧客の不満、チーム能力の無駄につながります。このような機会に対応する組織的取り組みを、ここではプログラムと呼びます。この記事では、うまくいかなかったプログラムの例を通して、プロダクトモード組織におけるプログラム管理に関する私たちの経験を共有します。

顧客企業がソフトウェア製品を購入する場合、通常はそれらをインストールするための熟練したスタッフが必要です。このスタッフは通常、サービスプロバイダー企業によって提供されます。ソフトウェア製品ベンダーは、独自のサービス部門を構築することがビジネスとして理にかなうとは考えていないためです。顧客は、製品ベンダーとサービスプロバイダーの関係を認識する必要があり、協力相手からその関係の透明性を求めるべきです。クラウドベンダーの台頭とともに、これらのパートナーシップが重要性を増すにつれて、ますます重要な透明性です。

エンタープライズアーキテクチャグループは、日常の開発から分離されることがよくあります。これにより、開発作業に関する彼らの知識が古くなり、開発チームが会社全体の広い視点を取らなくなる可能性があります。これが頻繁に起こるのを見てきた私の同僚（Thoughtworks CTO）Rebeccaは、エンタープライズアーキテクトは開発チームに参加することで、はるかに効果的になれると主張しています。

2008年のQConサンフランシスコで、Rebecca Parsonsと私は、アジャイルアプローチがエンタープライズアーキテクチャグループとどのように連携するかについて講演を行いました。現在、アジャイルプロジェクトチームとアーキテクチャグループの間には、多くの不信感と対立があります。その理由を掘り下げ、これらのグループが協力する方法を探ります。

最近、私の同僚であるNeal Ford、Rebecca Parsons、Pat Kuaが「進化型アーキテクチャ構築」という本を執筆しました。彼らから序文を執筆するよう依頼されたことを光栄に思います。

多くの企業は、次世代データレイクに投資しており、大規模なデータの民主化を期待して、ビジネスインサイトを提供し、最終的に自動化されたインテリジェントな意思決定を行うことを目指しています。データレイクアーキテクチャに基づくデータプラットフォームには、大規模な約束を果たせない共通の失敗モードがあります。これらの失敗モードに対処するために、レイクの中央集権的なパラダイム、またはその前身であるデータウェアハウスからシフトする必要があります。ドメインを最優先事項として考慮し、プラットフォーム思考を適用してセルフサービスのデータインフラストラクチャを作成し、データを製品として扱う、現代の分散型アーキテクチャから得られるパラダイムにシフトする必要があります。

コンウェイの法則（1968年にメルビン・コンウェイによって定式化された）は、システムの設計は設計者のコミュニケーションパターンによって制約されるというものです。Birgitta、Mike、James、そして私は、この原則の意味と、私たちのキャリアでそれがどのように展開されてきたかについて議論します。マイクロサービスの概念への影響、ビジネス能力との整合性の重要性、逆コンウェイ操作の役割について話します。

ソフトウェア開発において未解決の問題の1つは、ソフトウェアの境界を決定することです。（ブラウザはオペレーティングシステムの一部ですか？）。サービス指向アーキテクチャの多くの支持者は、アプリケーションは消滅しつつあると考えており、したがって将来のエンタープライズソフトウェア開発は、サービスを組み立てることになると考えています。

アプリケーション境界を決定するのが難しいのと同じ理由で、アプリケーションは消滅しないと私は考えています。本質的に、アプリケーションは社会的構築物です

私が好むソフトウェアアーキテクチャの実務家のほとんどすべてが、この分野における一般的な法則の種類を深く疑っています。優れたソフトウェアアーキテクチャは非常にコンテキスト固有であり、広範囲の環境で異なる解決策を提供するトレードオフを分析します。しかし、彼らがすべて同意する点が1つあるとすれば、それはコンウェイの法則の重要性と力です。私が遭遇したすべてのシステムに影響を与えるほど重要であり、それを打ち負かそうとすると敗北する運命にあるほど強力です。

各標準サイズのチーム内で、テクノロジーの種類ごとに代替案の選択肢を3つに制限します。これらは、現在の妥当なデフォルト、試行として実験しているもの、そして嫌いになって引退させたいものです。

最近、P of EAAについてAmazonでいくつかの悪いレビューを受け取りました。その理由は、この本にエンタープライズアーキテクチャに関する記述がないためです。もちろん、それには良い理由があります。この本はエンタープライズ *アプリケーション* アーキテクチャ、つまりエンタープライズアプリケーションを設計する方法について書かれています。エンタープライズアーキテクチャは異なるトピックであり、エンタープライズ内の複数のアプリケーションをどのように一貫性のある全体として組織するかについてです。

Thoughtworksが私をクライアントの前に出すと、必ず尋ねられる質問の1つは、「SOA（サービス指向アーキテクチャ）についてどう思いますか？」です。SOAは人によって意味が大きく異なるため、この質問に答えるのはほぼ不可能です。

大企業のソフトウェア資産など、大規模なソフトウェア開発には多くの人員が必要であり、多くの人員がいる場合、効果的なチームにどのように分割するかを考えなければなりません。ビジネス能力中心のチームを編成することで、ソフトウェア開発は顧客のニーズに対応しやすくなりますが、必要なスキル範囲はしばしばこのようなチームを圧倒します。チームトポロジーは、Matthew SkeltonとManuel Paisによって開発された、ソフトウェア開発チームの組織を記述するためのモデルです。4つのチーム形式と3つのチーム間の相互作用モードを定義しています。このモデルは、価値のあるソフトウェアの安定した流れを提供するというタスクにおいて、ビジネス能力中心のチームが成功するのを可能にする健全な相互作用を促進します。